Hardware implementation of process-based security protocol

ABSTRACT

A memory structure stores instructions for a method of providing access for a user to resources through a process. The process includes receiving user identification information and identifying user resource access information associated with the user identification information. The user resource access information includes process resource access information associated with a process. The process determines when an executing process attempts to accesses a specified resource and checks the process resource access information associated with the process when the process attempts to access the specified resource. The process determines if access to the specified resource by the process is permitted and allows the process to access the specified resource if access permission is indicated and denies the process access to the specified resource if access permission is not indicated.

TECHNICAL FIELD OF THE INVENTION

[0001] The present invention relates in general to software securitysystems and, more particularly, to a hardware implementation of asoftware security system.

BACKGROUND OF THE INVENTION

[0002] The general acceptance and use of data processing systems hasincreased significantly. Data processing systems of every scale andscope can be found in homes, small business, major corporations,schools, government offices and basically any organized concern.

[0003] A typical home data processing system may be configured to allowhome users to execute multiple computer programs. Each computer programmay access system resources such as memory devices, communicationdevices, printers and other devices. The computer program may read orwrite various stored data files. Access to the system resources andstored data files in a typical home system is governed by an“unrestricted” approach, i.e., any user on any system computer canaccess any program, any resource and any file.

[0004] Depending on the use a data processing system is performing, evensmall data processing systems may require a “restricted” approach tosystem resource access control. Large data processing systems typicallyrequire some level of “restricted” access control, as the number ofusers in a large system makes some kinds of access limitationsessential.

[0005] A data processing system may restrict access to system resourcesfor a variety of reasons. In many cases, the system includes stored datafiles that contain confidential or sensitive information. Resourceaccess may be limited to a specific group of users. The use of someresources may be billed on a per-use or time-used basis, requiringaccess to be controllable. Resource access may be controlled forefficient resource sharing.

[0006] In restricted access systems, a user may be assigned a systemidentifier, typically a user ID. A system administrator configures thedata processing system by creating a configuration file associated withthe user. The associated configuration file defines the user's access tosystem resources, once the user has logged in to the system. The systemadministrator may configure a user's access to a stand-alone system oraccess to a networked system, For example, in the network environment,the system may include a plurality of network drives, network resourcessuch as printers, faxes and mailboxes, etc.

[0007] Each user has a configuration file associated with the user. Theassociated configuration file defines which system resources the usercan access. When the user has logged into the system, the network readsthe configuration file associated with the user and allow that useraccess to identified system resources. When the user executes a program,system may check to see if the user has access to the program. When thecomputer program tries to access system resources through the operatingsystem or other access processes, the system checks the configurationfile to see if the user has access to the system resources. Thedisadvantage to this type of access is that the user has full access tothe identified resources for any purpose. Particularly, the user may beable to access the identified resource for purposes other than thepurpose for which the user was given access. This kind of access may besubject to many types of abuses.

[0008] As an example, a user may be given access to a modem for use withdatabase searching software. This database searching software connectswith a provider using the modem. The database searching softwareperforms predefined searching via the modem connection. In order for theuser to get access to the modem in a restricted system, the user'sassociated configuration file may grant access to a given serial portconnected to a modem. However, in this scheme, the associatedconfiguration file gives the user access to the modem, even when theuser is using software other than the database searching software toaccess to the modem. The user may run other programs that can gainaccess to the system. The disadvantages to this is that, although thedatabase searching software may have certain restrictions that areinherent in the software itself, a user can bypass this system toutilize the modem for other purposes.

[0009] This can also be the case with respect to data files. A wordprocessing program may have the ability to read and write files.However, this access is granted in a global manner. Where the user hasaccess to the files, the access is universal, regardless of the methodof access.

[0010] As another example, a database may allow access to sensitivedatabases, databases that may include personal or confidentialinformation such as payroll, criminal records, etc. A user's access tothe database is written in the associated configuration file. The user'saccess to the database, once granted, is permitted, without regard forthe scope of uses the user might employ. With current operating systemsecurity, the user can certainly go outside of a given program that isutilized with a specific database to copy, delete or even change filesin the database outside of the program. As such, there exists a problemin that security for current operating systems provides that resourcesare allocated based on users or the groups to which the users belong.This therefore allows the user access to those resources even though theprocess that needs those resources is not being run. These rights willin turn allow the user to use the resource outside of its intended use.

[0011] In a typical general purpose computer system operating with awide assortment of applications or processes, usually as part of abundled package, security is based on the control of user access. Thetypical system allows users access to all of the resources on the systemwhether they are needed or not. A disadvantage of this system is that itis not very secure and is prone to break-in or misuse of resources, someof which contain very sensitive information, primarily because of theunrestricted access to resources. Once a user is authenticated to thesystem, generally by entering a user ID and a password, access to thesystem is unlimited. One solution, implementing process-based access toa general purpose computer system, where the access to each resource iscontrolled in addition to the entry of a user ID and password, wouldprovide an additional level of access control.

SUMMARY OF THE INVENTION

[0012] A memory structure stores instructions for a method of providingaccess for a user to resources through a process. The process includesreceiving user identification information and identifying user resourceaccess information associated with the user identification information.The user resource access information includes process resource accessinformation associated with process. The process determines when anexecuting process attempts to accesses a specified resource and checksthe process resource access information associated with the process whenthe process attempts to access the specified resource. The processdetermines if access to the specified resource by the process ispermitted and allows the process to access the specified resource ifaccess permission is indicated and denies the process access to thespecified resource if access permission is not indicated.

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] For a more complete understanding of the present invention andthe advantages thereof, reference is now made to the followingdescription taken in conjunction with the accompanying Drawings inwhich:

[0014]FIG. 1 illustrates a block diagram of an overall system;

[0015]FIG. 2 illustrates a prior art security system;

[0016]FIG. 3 illustrates a general block diagram of the system of thepresent invention;

[0017]FIG. 4 illustrates a more detailed block diagram of the system ofthe present invention;

[0018]FIG. 5 illustrates an alternate embodiment of the system of thepresent invention;

[0019]FIG. 6 illustrates a flowchart depicting the operation of thepresent invention;

[0020]FIG. 7 illustrates a flowchart depicting the resource request bythe process;

[0021]FIG. 8 illustrates a flowchart depicting the processing of therequest by the operating system;

[0022]FIG. 9 illustrates a functional block diagram of an embodiment ofa process-based security system according to the present disclosure;

[0023]FIG. 10 illustrates a flowchart of the operation of the embodimentof the process-based security system of FIG. 9;

[0024]FIG. 11 illustrates a flowchart of an example of use of a resourceaccess table according to the embodiment of FIG. 9;

[0025]FIG. 12 illustrates a functional block-diagram of a multi-userprocess based security system according to the disclosure;

[0026]FIG. 13 illustrates a flowchart of an authentication process usedin a process based security system;

[0027]FIG. 14 illustrates a flowchart of a set password process used ina process based security system;

[0028]FIG. 15 illustrates a flowchart of a key exchange process usedwith a process based security system;

[0029]FIG. 16 illustrates a flowchart of a financial transaction using aprocess-based security system;

[0030]FIG. 17 illustrates a flowchart of a secure file transfer processusing a process-based security system;

[0031]FIG. 18 illustrates a flowchart of a self-rebuilding function;

[0032]FIG. 19 illustrates a flowchart of a table building process inaccordance with one embodiment;

[0033]FIG. 20 illustrates a flowchart of a table building process inaccordance with a second embodiment;

[0034]FIG. 21 illustrates a functional block diagram of an embodiment ofa process-based security system using intrusion detection; and

[0035]FIG. 22 illustrates a flowchart of a table building process usingintrusion detection.

[0036]FIG. 23 illustrates a functional block diagram of hardwareimplementations of a process-based security system.

DETAILED DESCRIPTION OF THE INVENTION

[0037] Referring now to the drawings, wherein like reference numbers areused to designate like elements throughout the various views, severalembodiments of the present invention are further described. The figuresare not necessarily drawn to scale, and in some instances the drawingshave been exaggerated or simplified for illustrative purposes only. Oneof ordinary skill in the art will appreciate the many possibleapplications and variations of the present invention based on thefollowing examples of possible embodiments of the present invention.

[0038] Referring now to FIG. 1, there is illustrated an overall blockdiagram of a data processing system operating in conjunction with thesecurity system of the preferred embodiment. A central processing unit(CPU) 10 is provided. The CPU 10 may have associated therewith amicroprocessor, memory, peripheral circuitry, power supply, etc., asrequired to execute instructions and, in general, run computer programs.

[0039] The CPU 10 may have associated external therewith a keyboard 12to allow the user to input information thereto. The CPU 10 may also beconnected to a display 14 for visually displaying output. A disk inputsystem 16 may also be provided to allow the user to store and retrievedata to disk. The CPU 10 is typically connected to local memory 18associated therewith. The local memory 18 may take the form of randomaccess memory, read-only memory, flash memory or other forms of memory.

[0040] The CPU 10 may also include peripheral storage devices includingflash memory, optical disk drives such as CD or DVD drives, hard drives,disk drives or any other form of data storage. The local memory 18 isoperable to store both files in a region 20 and also execute programs ina region 22. The files in the region 20 can also consist of data fordatabases. The CPU 10 can then access the executable files in theprogram portion 22, execute the programs and access information in theform of files and/or data.

[0041] CPU 10 also interfaces with peripheral resources through anInput/Output (I/O) block 24. The I/O block 24 allows access to suchthings as a modem 26, a network card 28, a scanner 30 and a printer 32.The scanner 30 and the printer 32 are referred to as local resources.The modem/fax 26, however, allows access to remote resources, such as apublic telephone network (PTN) 34. The network card 28 allows access toa network 36, which in turn allows access to network resources 38.

[0042] Referring now to FIG. 2, there is illustrated a block diagram ofa prior art security system. In prior art security systems, a userrepresented by a block 40 is allowed to access the system only uponproviding the correct user I.D. A system administrator 42 is operable topre-store configurations for the users in a user resource accesstemplate 44. This user resource access template is accessed whenever auser is brought into the system and attempts to log in to the system.Once the user logs in, each user is given a predetermined configuration,this referred to as user access blocks 46, there being one associatedwith each user. Each of these user access blocks 46 contain theconfiguration that was pre-stored by the system administrator 42 in theuser resource access template. Once configured, this defines how theuser is interfaced with the system, the system comprised of a pluralityof system resources, represented by blocks 48. In the exampleillustrated in FIG. 2, there are provided five system resource blocks48.

[0043] It can be seen in the prior art system of FIG. 2 that there arethree user access blocks 46, representing three different userconfigurations, although there could be more, and five separate systemresources, although there could also be more of these. The user accessblock associated with the user No. 1 is associated with system resource1 and system resource 2. User access block 46 associated with user No. 2has access to system resource No. 1, system resource No.3 and systemresource No. 4. Associated user access block 46 provides a configurationthat allows user No. 3 access to system resource 1 through 5. It isnoted that this is independent of the process upon which the user isworking. The system resource is accessible by the user and not by theprocess.

[0044] Referring now to FIG. 3, there is illustrated an overall blockdiagram of the present invention. In the present invention, security isbased upon a process. A process, such as a word processing program, afinancial program, etc., each have certain needs related to theresources. For example, a payroll program, once accessed, would need tohave access to its database. The program, however, typically does notallow as an inherent part thereof for the database to be copied, doesnot allow the database to be deleted nor manipulated in any manner otherthan that provided by the program itself. These may even have audittrails that cannot be bypassed. The present invention provides forsecurity wherein the resource is only accessible through the step ofexecuting and running the program. If the program is not running, theuser does not have access to the given resource unless through anotherprocess which happens to have access to the resource.

[0045] Referring further to FIG. 3, a general operating system 60 isillustrated, this operating system being any type of operating systemsuch as a Microsoft Windows based system, a UNIX system or even a DOSsystem. An operating system is the primary method by which a computerinterfaces between the peripheral systems, such as memory storagedevices, printers, modems and a process running on said computer. Theuser is then provided with a platform on which to run programs whereinthe user can access the program and have the program access variousperipherals through its interaction with the operating system. Operatingsystem 60 therefore provides the necessary commands to access variousresources 62 on the system. Again, these resources can be such things asa modem, a printer, a scanner, etc., even including a magnetic diskdrive. The operating system is restricted to allocate only thoseresources defined in a resource access table 64, which resource accesstable defines resources associated with a given process, whichassociation is based upon the process' needs.

[0046] The process expresses its need via a process requesting mechanism66 which is an inherent aspect of process execution for any givenprocess. The process requesting mechanism 66 initiates a request for aresource and, if the process running on the system has access to thatresource, as noted in the resource access table 64, the operating system60 will then grant the resource for use by the process within theoperating system. If not, then the operating system will block access.

[0047] Referring now to FIG. 4, there is illustrated a more detailedblock diagram of the process-based access system of the presentinvention. In general, a user block 68 is provided which indicates auser of the system. The user of the system can access any given process,being illustrated for processes in process blocks 70. Each of theprocess blocks 70 is connected to a process access selector 74, each ofwhich is associated with one of the resource blocks 62, there beingillustrated five resource blocks 62. The process access selector 74 isoperable to potentially allow any process to address that process accessselector 74. An access control block 76 is provided that receives asinputs an indication of which of the processes in process block 70 isrunning. A System Administrator block 75 is provided to allow a SystemAdministrator to set the parameters of the access control block. Theaccess control block then selects which of the process access selectorblocks 74 is authorized to have access to a given resource. It isimportant to note that it is a request from a process block 70 duringthe running of that process that is utilized by the access control block76 to grant access to the process access selector 74.

[0048] By way of example, if a word processing program were beingoperated and, on the same computer, a user had the ability to operate anaccounting program, the word processor would be provided access tocertain regions on a disk and the files associated therewith. The usercould retrieve these files, delete them, modify them and restore them.However, the user would not be allowed through the word processor toaccess the accounting database for any purpose, since the process doesnot require this. In another example, if a modem were provided, thiswould not usually be a resource that was available to a word processor.The modem would, for example, only be accessible to a communicationsprogram.

[0049] In another example of the operation of the process based securitysystem, where resources are permitted access only in association withthe particular process that is selected, reference is made to Table 1,which is an example of the resource access table 64 of FIG. 3: TABLE 1Step Process name Resource name Rights Mask 1 C:\*.*/S C:\*.*/S Fullaccess E:\LOGIN\LOGIN.EXE Execute only 2 E:\LOGIN\LOGIN.EXEE:\SYSTEM\PASSWORDS Read only E:\PROGRAMS\MENU\MENU.EXE Execute only 3E;\PROGRAMS\MENU\MENU.EXE E:\PROGRAMS\MENU\SCREENS Read onlyE:\PROGRAMS\*.EXE/S Execute only E:\PROGRAMS\*.COM/S Execute only 4E:\PROGRAMS\WP51\WP.EXE F:\LIBRARY\*.* Full access G:\COMMON\*.*/S Fullaccess

[0050] The example in Table 1 illustrates a general personal computer ofthe clone type, running an MS DOS operating system which is attached toa network with a process based security. When the computer is started,any process with the C:\ drive (denoted with the wild card processing of*.*) and its sub-directories (denoted with the /S option on the end ofthe process name) is provided full access to anything on the C:\ drive(once again denoted with the wild card resource name of *.*) and itssub-directories (once again denoted with the /S option on the end of theresource name). The user can also execute the process E:\LOGIN\LOGIN.EXEfrom the network. All other resources from the network are not availableto the computer at this time. This situation represents a user, on acomputer, who can log into a network, but has not done so. In essence,the user can do anything with their local resources, but nothing withnetwork resources, until they are identified to the network with thelogin program.

[0051] In step 2 in Table 1, when the user executes theE:\LOGIN\LOGIN.EXE process, the process changes from something on C:\ toLOGIN.EXE which can read the E:\SYSTEM\PASSWORDS file and execute theE:\PROGRAMS\MENU\MENU.EXE program. The file LOGIN.EXE is the network'smethod of identifying users of the network. Execution of LOGIN.EXE willverify the user through its read-only access to the E:\SYSTEM\PASSWORDSfile. If the user is verified as a valid user, LOGIN.EXE will passcontrol on to step 3 and the process E:\PROGRAMS\MENU\MENU.EXE.

[0052] In step 3, when MENU.EXE gets executed, it will read theappropriate menu options from its SCREENS file and display it for theuser. MENU.EXE controls what programs can be executed and as such, ithas been given rights to execute any program in the E:\PROGRAMSdirectory or any of E:\PROGRAMS sub-directories (this is denoted withthe /S option after the partial wild card name *.EXE and *.COM). In step4, in the event the user executes the WP.EXE program, this process hasfull access to a local F:\LIBRARY directory, a shared G:\COMMONdirectory and the sub-directories of G:\COMMON. The example in step 4may also represent a network, where personal files are stored in auser-related directory (F:\LIBRARY) and company shared documents arestored in a common directory (G:\COMMON).

[0053] In the preceding example, it can be seen that the user cannot,for example, obtain access to the PASSWORDS file by any other processexcept for the LOGIN.EXE process and this process determines how theuser can deal with that particular file.

[0054] Referring now to FIG. 5, there is illustrated an alternateembodiment of FIG. 4, illustrating how a particular process canconstitute a resource. The resource blocks include a resource block 80which constitutes a sixth resource, in addition to the five resourceblocks 62. However, this resource also has a process block 82 disposedtherein, which constitutes a fifth process. Access to this process block82 is facilitated through the use of a process access block 84, similarto the process access block 74, and controlled by access control 76.Each of the processes in process blocks 70 have access to the processblock 82 and the resource block 80 through the process access block 84.Therefore, if one of the processes in process blocks 70 were running andthe access control block 76 allowed access through a process accessblock 84, then process No. 5 in resource block 80 could be run. This, ofcourse, would then allow process block 82 and the process #5 associatedtherewith to request and receive access to any of the resources inresource blocks 62 associated with process access block 74 in accordancewith the access control information in access control block 76. Althoughillustrated as only a single process that is accessed by anotherprocess, there could be many processes deep, such that three or fourprocesses would need to be run before a given process was accessiblewhich, in turn, could access an end resource.

[0055] It is important to note that the process must be running and,during the running thereof, execute instructions that request a givenresource. It is the running of the process and the request by thatrunning process that allows access to a resource. The fact that theprocess has been opened and initiated is not sufficient to gain accessto the resource since it is the use of the resource by a given processthat is selected. For example, if a multi-tasking operating system wereutilized and a given program executed from that platform as a firsttask, it may be desirable to place that task in the background andinitiate a second task. Even if the first task were running in thebackground, the ability of the first task to request a given resourcedoes not in any way effect the rights of the second task to have accessto that same resource. Unless it is in the resource access table, noaccess to the resource will be allowed. Even if the first task wereoperating and it were utilized to “launch” a second process, this wouldnot effect the resource access of the launched process, since when thelaunched process is running, the launching process is not running and itis not the launching process that is requesting access to the resource.Therefore, it is only the requesting resource that is of concern.

[0056] Referring now to FIG. 6, there is illustrated a flowchartdepicting the overall operation of the system. The program is initiatedat a start block 100 and proceeds to a decision block 102. The decisionblock 102 determines if a process has been initiated. If not, theprogram flows back around an “N” path to the input of decision block102. When a process has been initiated, the program will flow to afunction block 104 to log in the user. The log in procedure is aprocedure that may be utilized, but can be optional. In and of itself,as described above with reference to Table 1, the log in process is aseparate process in and of itself. However, some programs by themselves,require log in procedures, i.e., accounting systems. Therefore, this isan optional block.

[0057] After the log in block 104, the program will flow to a functionblock 106 to run the process. Once the process is running, the programthen flows to a decision block 108 to determine if a resource requesthas been made by the running process. If not, the program will flowalong the “N” path back to the input of function block 106. When aresource request has been made by the running process, the program willflow from decision block 108 along a “Y” path to a function block 110,wherein the resource access table is accessed to determine access rightsfor the requesting process. The program will then flow to a decisionblock 112 to determine if access has been granted for that particularresource. If not, the program will flow along a “N” path to a functionblock 114 to return an “access denied” error code. The program will thenflow back to the input of function block 106. However, if access rightshave been granted in accordance with the resource access table, theprogram will flow along a “Y” path from decision block 112 to a functionblock 116 to allow access to the system and then back to the input offunction block 106. This will continue unless the resource is halted.

[0058] Referring now to FIG. 7, there is illustrated a flowchartdepicting the resource request by the process, as in step 108 of FIG. 6.The flowchart is initiated at a block 120 and then proceeds to adecision block 122, wherein the process determines if a resource isneeded for the process. If not, the program flows along an “N” path backto the input of decision block 122. If a resource is required, theprogram will flow along a “Y” path to a function block 124. The functionblock 124 then determines the ID for the resource and then generates therequest, this request defining the resource that is required and alsothe mode of access that is required. The program will then flow to adecision block 126 to determine if the resource is available. If not,the program will flow along an “N” path back to the input of decisionblock 122. If it is available, the program will flow along a “Y” path toa function block 128 to process the resource in accordance with theoperation of the process and then flow to a return block 130.

[0059] Referring now to FIG. 8, there is illustrated a flowchartdepicting the operation of the operating system when processing arequest for a resource. This is initiated at a block 134 and thenproceeds to a decision block 136. The decision block 136 determineswhether a resource request has been received from a process operating inconjunction with the operating system. If not, the program will flowalong an “N” path back to the input of decision block 136. If a resourcerequest has been received, the program will flow along the “Y” path to afunction block 138. Function block 138 fetches the information stored inthe resource access table to determine if the particular resource hasany access rights associated therewith. The program will then flow to adecision block 140 to determine if access rights are present in theresource access table for the requested resource. If not, the programwill flow along the “N” path to a function block 142 wherein a “NULL”signal is sent back to the requesting process to deny access and then tothe input to decision block 136.

[0060] If access rights exist in the resource access table for the givenresource, the program will then flow to function block 144 to determineif the mode of access that is requested by the requesting process ispresent in the resource access table, i.e., whether the resource accesstable has been set up to grant this mode of access to the givenresource. An example of this would be a file that is defined as theresource with the modes being READ and WRITE, with either reading of thefile from the disk or writing of the file to disk. The program will thenflow to a decision block 146 to determine if the mode of access isavailable. If not, the program will flow along the “N” path back to thefunction block 142 and, if the mode of access is available, the programwill flow along the “Y” path to a decision block 148 to determine if therequested resource and mode of access are valid for the requestingprocess. For example, a process may request access to a particularmemory device or portion of a memory device and it may require access tothat memory device for writing of information thereto. The system willfirst determine if the resource has access rights associated therewithand then check to see what mode of access is allowed. In this example,if the resource is available, it may have a mode of access available forreading and a mode of access available for writing. However, theresource access table may only grant reading rights to the requestingprocess. In this event, access will be denied. This is represented bythe path that flows along the “N” path back to function block 142. Ifaccess is allowed, the program will flow along a “Y” path from decisionblock 148 to a function block 150 to grant access and then to a returnblock 152. The following is the process flow for the process generatingthe request: Process id = fopen (“filename”, “rt”);   

This is the request to   the operating  system for the file access(resource). if (id == NULL) { file not available } else { process theopened file }

[0061] The following is the process flow for the operating system whenservicing the request: Operating System FILE *fopen (char *name, char*mode)   {     (before checking for the presence of the file,     checkto see if the process has any rights to the file.) for (I = ø;i<SIZE_OF_ACCESS_TABLE; i + +)  if (check (name, accesstable [i].resource) == ø)   break; if (i == SIZE_OF_ACCESS_TABLE) return NULL; (norights at all) for (j = ø; j< accesstable [i]. rights_size; j ++)  if(check (mode, accesstable [i]. rights [j]. Mode) == ø)   break; if (j ==accesstable [i] rights size) return NULL; (specific right not present)  (the remaining code deals with what the operating   system needs to doto allocate the file to the calling   process (note additional errorsmay still occur, like   file not found)).   }

[0062] The foregoing describes a system for providing process-basedsecurity to an operating system. In this security system, access to anyresource on the system, although provided by the operating system, isrestricted by the operating system to only those requested by a givenprocess. Whenever a process, during operation thereof with the operatingsystem, requires or requests access to a resource, the operating systemmakes a determination as to whether a resource can be made available forthat given process. This is facilitated by storing access rights for anyprocess in a resource access table. When a process is running on thesystem and it requests for its use a given resource, the operatingsystem will then look up in the resource access table to determine ifthe resource is available and, if so, grant access to the resource.

[0063] It has been described hereinabove that a process-based securitysystem controls access to resources via the process (i.e., application)that requests the resource. Experimentation and development have shown,however, that such a security system is is particularly efficient whenimplemented in a dedicated, or single-purpose environment, such as a webserver, or other, computer appliance-type of application.

[0064] Thus, it can be appreciated that the process-based securitydescribed hereinbelow, as applied to a dedicated, single purposecomputer system, could exhibit the following advantages:

[0065] (1) prevent a user from loading their own applications into thesystem;

[0066] (2) prevent a user from attempting to access files fromuncontrolled processes, e.g., trying to load in a hex editor to obtainaccess to the sensitive files such as accounting records, etc.;

[0067] (3) prevent access to all the resources in a system, even thoughindividual resources are needed by a particular program or process;

[0068] (4) process-based security, in a dedicated environment, is selfcontained, i.e., independent of the rest of the system, and is thusrelatively easy to implement in existing systems;

[0069] (5) process-based security is context-specific or can be made tobe dynamic by the way in which resource access is interpreted; and

[0070] (6) in a process-based security system, the user only has theright to execute a specific application or process and that processincludes access rights only to specific resources keyed to therequesting process.

[0071] Referring to FIG. 9 there is illustrated a functional blockdiagram of an illustrative embodiment of a process-based security systemaccording to the present disclosure. A portion of the functional aspectsof a complete computer system 160 is shown having an operating system162 coupled with a plurality of resources indicated by the three blocksidentified by reference number 172, respectively resource A, resource Band resource C. In general, resources 172 may be various types of inputand/or output devices or application programs installed on a particularsystem. I/O device resources may include a keyboard, mouse, scanner,display, modem, disk drive, printer, or an interface to a network, etc.Application, or process type resources may further include a wordprocessor, a spreadsheet, a communication or e-mail program, a database,a search engine or browser and the like. Continuing with FIG. 9, eachprocess requesting access 168 is bound to a resource access table (RAT)164 via respective links 165, 166 and 167. The resource access tables164 contain entries or statements that may be expressed in a high levelprogramming language. Further coupled as inputs to operating system 162are the plurality of processes requesting access 168, i.e., applicationsrunning on system 160 as indicated by process requesting access 1,process requesting access 2 and so on to process requesting access N. Inthe description to follow, the words application and process will beused interchangeably, referring generally to an application program asdistinguished from an operating system. Such application programs areprovided to accomplish specific operations such as spread sheets or wordprocessing or communications and the like. In general, each of theseprocesses or applications 168 will, during their operation, requireaccess and use of various ones of the resources 172 coupled to theoperating system 162 of the computer system 160 of the presentdisclosure. Coupled as inputs to the various processes 168 orapplications 168 is provision for entering a user identifier and/orpassword for each respective process 168 or application 168 that will berequesting access to a resource as will be described furtherhereinbelow. The entry of the user identifier and/or password isrepresented by the functional block 170 user ID and password.

[0072] Referring further to FIG. 9, an operating system 162 for computersystem 160 is illustrated, such as a Microsoft Windows based system, aUNIX system, a DOS system or the like. An operating system is theprimary method by which a computer interfaces with the various resourcesincluding, for example, the peripheral systems such as memory storagedevices, printers, modems and a process or application running on saidcomputer. The operating system 162 provides the user with a platform onwhich to run programs, i.e., applications or processes 168 wherein theuser can access the program and have the program access variousperipherals through its interaction with the operating system. Operatingsystem 162 therefore provides the necessary commands to access variousresources 172 on the system. Further, the operating system 162 isrestricted to allocate only those resources defined in the resourceaccess tables 164, which define resources 172 to be associated with agiven process 168, based upon the needs of the process 168.

[0073] The operating system 162 (OS 162) receives as inputs anindication of which of the process blocks 168 is running. In oneembodiment the OS 162 may include or be responsive to a SystemAdministrator function to set the parameters of the access control forthe resources 172. The OS 162 in conjunction with the resource accesstable 164 then selects which of the resources 172 is authorized access.It is important to note that it is a request from a process 168 duringthe running of that process 168 that is utilized by the OS 162 to grantaccess to the resource access table 164.

[0074] Continuing with FIG. 9, the functional block 170 indicates both auser of the system and information that may be provided by the user togain access to the system or its resources. The user of the system canaccess any given resource appropriate to the application that isprovided in the dedicated system. In general, a process or anapplication is an executable file which may be referred to as “*.EXE”,the “*” defining a wild card name of one or more characters representingan executable file or program. For example, one well known wordprocessing program has an executable file name of WP.EXE. The user canenter the term “WP” and “launch” that program. The program will then runin a conventional manner.

[0075] In operation of the system 160 of FIG. 9, by way of example, if aword processing program were being operated and, on the same computer, auser had the ability to operate an accounting program, the wordprocessor would be provided access to certain regions on a disk and thefiles associated therewith. The user could retrieve these files, deletethem, modify them and restore them. However, the user would not beallowed through the word processor to access the accounting database forany purpose, since operation of the word processor process does notrequire this. In another example, if a modem were provided, this wouldnot usually be a resource that was available to a word processor. Themodem, for example, could only be accessed by a communications program.

[0076] In an example of the operation of a process based securitysystem, reference is made to Table 2: TABLE 2 Process or applicationStep name Resource name Rights Mask 1 C:\*.*/S C:\*.*/S Full accessE:\LOGIN\LOGIN.EXE Execute only 2 E:\LOGIN\LOGIN.EXE E:\SYSTEM\PASSWORDSRead only E:\PROGRAMS\MENU\MENU.EXE Execute only 3E;\PROGRAMS\MENU\MENU.EXE E:\PROGRAMS\MENU\SCREENS Read onlyE:\PROGRAMS\*.EXE/S Execute only E:\PROGRAMS\*.COM/S Execute only 4E:\PROGRAMS\WP51\WP.EXE F:\LIBRARY\*.* Full access G:\COMMON\*.*/S Fullaccess

[0077] For purposes of illustration, the example in Table 2 applies to apersonal computer (PC) which is attached to a network and running an MSDOS operating system that is provided with process-based security.Although a PC is usually considered a general purpose system, thesimplicity of the illustration provided by Table 1 applies equally wellto a dedicated computer system. When the computer is started, as in step1 in Table 1 described previously, any process to be run with the C:\drive (denoted with the wild card designation *.*) and itssub-directories (denoted with the /S option on the end of the processname) is provided full access to any resource on the C:\ drive. Notealso that the user can execute the resource E:\LOG\IN\LOGIN.EXE from thenetwork but that all other resources from the network are not availableto the computer at this time as being limited by the statementE:\LOGIN\LOGIN.EXE. This statement will be described further in the nextparagraph. This example, so far, represents a user, on a computer, whocan log into a network, but has not done so. In essence, the user can doanything with his or her local resources, but nothing with networkresources, until they are identified to the network with the loginprogram.

[0078] In step 2 in Table 2, when the user executes theE:\LOGIN\LOGIN.EXE process, the process changes from something on C:\ toLOGIN.EXE which is permitted to read the E:\SYSTEM\PASSWORDS file andexecute the E:\PROGRAMS\MENU\MENU.EXE program. The file LOGIN.EXE is thenetwork's method of identifying users of the network. Execution ofLOGIN.EXE will verify the user through its read-only access to theE:\SYSTEM\PASSWORDS file. If the user is verified as a valid user,LOGIN.EXE will pass control on to step 3 and the processE:\PROGRAMS\MENU\MENU.EXE.

[0079] In step 3, when the file MENU.EXE is executed, it will read theappropriate menu options from its SCREENS file and display it for theuser. MENU.EXE controls what programs can be executed and as such, ithas been given rights to execute any program in the E:\PROGRAMSdirectory or any of E:\PROGRAMS sub-directories (this is denoted withthe /S option after the partial wild card name *.EXE and *.COM as listedin the resources column of Table 2). In step 4, in the event the userexecutes the WP.EXE program, this process has full access to a localF:\LIBRARY directory, a shared G:\COMMON directory and thesub-directories of G:\COMMON. Step 4 may also represent a network, wherepersonal files are stored in a user-related directory (F:\LIBRARY) andcompany shared documents are stored in a common directory (G:\COMMON).

[0080] In the preceding examples illustrated by Table 2, it can be seenthat the user, because of the table which must be accessed during aresource request, cannot obtain access to the PASSWORDS file by anyother process except via the LOGIN.EXE process. This process alsodetermines how the user can deal with that particular file.

[0081] Referring now to FIG. 10 there is illustrated a flowchart of theoperation of the illustrative embodiment of the process-based securitysystem of FIG. 9. The flow begins with the Start block 200 and proceedsto block 204 to load the application program. From block 204 the flowproceeds to block 206 to start the application which is followed bydecision block 208 to determine whether a resource is requested by theapplication. If the result of the determination is negative then theflow follows the N path back to the entry to the Start Application block206. If the determination in block 208 is affirmative then the flowproceeds to block 218 wherein a step to read the respective resourceaccess table 164 for the requesting application 168 is performed.

[0082] Continuing further with FIG. 10, upon reading the resource accesstable 164 for the requested application in block 218 the flow proceedsto block 220 wherein the system 160 interprets the entries or statementsin the resource access table 166 to identify the commands of theexecution path and the sequence of operations contained in it. The flowthereupon proceeds to decision block 222 wherein a determination is madeas to whether the request for resource access matches the application inoperation. If the determination is negative, then the flow proceeds toblock 216 wherein access is denied and thereupon is routed back to thestart application block 206. If, however, the determination in decisionblock 222 is affirmative, then the flow proceeds along the Y path toblock 226 wherein access is granted to the requested resource and theflow returns to the main program to execute the application or processas indicated at block 234. It will be appreciated that the securityaccess is provided by the reading and interpreting of the resourceaccess table 164 entries or statements which specify the resourcesneeded for the particular application or process and the execution pathfor access to those resources. Thus, access to resources is limited toonly those resources that are needed and requested by the particularapplication or process that is in operation.

[0083] A study of FIGS. 9 and 10 described hereinabove will reveal thefollowing operational characteristics of a process-based security systemfor dedicated or single-purpose computer systems. Upon launching anapplication in a process-based system, the access rights are associatedor bound to the launched application as indicated by links 165, 166 and167 in FIG. 9. During the request for access to the needed resource(s),the access rights associated with that program are checked. In a generalpurpose system, security checks impede processing by interrupting the OSwhile the security check is performed each time a user requests aresource. In a dedicated system running one process or a single processcombination, only one request for resource access is required; ifseveral process combinations are provided, the system selectively allowsaccess to the resources appropriate to the process requesting access. Ineither case, the request occurs during the initial steps of the process.Further, the security access is performed by matching the conditionspresent upon launching the application such as the program identity,user identity and password, execution path through the directory, etc.with the resource access entries or statements in the respectiveresource access table 164. Once the application is launched, read andwrite calls are no longer checked, and the resource access table 164controls “the traffic”—the execution path through the directory. As anexample, in a web server application, the steps, briefly, would be: (1)turn on the web server; (2) launch the application; (3) read andinterpret the resource access table entries; (4) grant the neededaccess; and (5) execute the application, including the allowedresources.

[0084] During the interpretation step 220 of FIG. 10 of the illustratedembodiment, resource access table entries are interpreted, one characterat a time, instead of merely reading a resource name associated with alisted process or merely making a string comparison, because of thepresence of meta symbols embedded into the entries in the respectiveresource access table 164. Meta symbols, as disclosed herein, aretextual devices which may be inserted into resource access table entriesas second-order data or instructions to supply additional relatedinformation or modify the interpretation of the entry in some way. Inthe comparison process to find a resource in the resource access table,entries do not have to be static. Entries in the resource access tablecan have meta symbols to allow for context sensitivity to the processmaking the request. Table 3 presents some examples of meta symbolsdeveloped for the embodiment of the present disclosure which may beincluded in a resource access table entry. Meta symbols are assigned—andconstrued—in a UNIX environment. TABLE 3 Meta Symbol Definition/Meaning$P If the requested resource name matches to this point, consider theentry a match (path wild-card). $C The particular character in therequested resource name matches this symbol no matter what (characterwild-card). $D For a single level of depth in the directory, this symbolmeans a match (directory wild-card). $$ Requested resource name mustmatch a $ at this point. $S Requested resource name must end (suffix) inthe text following this symbol. $U Requested resource name must have theuser name of the user that initiated the process making the request, atthis point. $G Requested resource name must have the group name of thegroup that initiated the process making the request, at this group.

[0085] As described in the foregoing, to provide process-based securityaccess in a single-purpose “appliance” computer system, a resourceaccess table (RAT) is bound to, i.e., associated with, the requestingprocess when the process or application is launched. The RAT containsentries in which the defined execution paths, i.e., process paths, aremodified using meta symbols. These meta symbols provide instructions forinterpreting the process or execution paths. For example, meta symbolentries enable the system to determine which part(s) of an entry in aRAT must be matched character-by-character to produce a valid comparisonor which part(s) may be ignored or which part(s) has a substitutedinstruction, etc., in order to be granted the security access rightsassociated with that particular entry in the RAT. Each entry orstatement in the RAT may correspond to a resource whose access isdefined by the entry.

[0086] For example, an unmodified entry in a RAT might appear as:

[0087] PROGRAMS/WP/WP.EXE

[0088] and the resources to be associated therewith might be:

[0089] /HOME/$U/$P.

[0090] So, when a user initiates a program operation the command stringis compared to the RAT entry. In this example, the meta symbol $U meansthat the current user name is substituted into the entry and permittedaccess to the respective resource. Similarly, the $P modifies the RATentry and means that the rest of the path is ignored, i.e., it is“matched” no matter what the rest of the path is.

[0091] Example No. 1: Referring now to FIG. 11, suppose the user Q isoperating in the home directory and wishes to delete a file xyz. In FIG.11, the perspective is that of the operating system. The routine beginswith the start block 240 and proceeds to function block 242 wherein theoperating system (OS) receives a request to run DEL program. Thereafterthe OS checks in block 244 whether the current user is allowed a DELcommand. If not, the flow follows the N path and returns to enter block242. If so, the flow proceeds to block 246 to load the DEL command andfetch the corresponding access rights from the resource access table(RAT) 166. In this case the RAT 166 entry is the statement: /HOME/$U/$Pwhich defines access rights in the HOME directory for the $U currentuser within which access is allowed $P from this point on, i.e., isunrestricted in directory depth per Table 3.

[0092] Continuing with FIG. 11, in the next step, at decision block 248,the OS determines whether the access rights match the current user andif affirmative, the flow proceeds along the Y path to another decisionblock 250. There, if both the HOME directory and the current user $U arematched, the routine advances to block 252 where access is granted andthe DEL command is allowed to be executed. The routine returns to themain program in block 254. In either case, in blocks 248 or 250, theresult is that a match did not occur, access is denied and the routinereturns to the entry of block 242.

[0093] Example #2: Suppose the user is operating in the HOME directory,and wishes to run a word processor (e.g. WordPerfect). The wordprocessor program (application or process) is in the directory:/PROGRAMS/WP/WP.EXE. Here, the resource access table statement is:/HOME/$U/$S.WP, where $S is used as an intervening suffix. Thisstatement limits access to files in the user's home directory(/HOME/$U/) that end in the characters .WP ($S.WP).

[0094] It will be appreciated in the foregoing example that any resourcecan be moved to any place in an execution path it is desired, merely bydefining the access rights for that path in the Resource Access Table.Thus, the access rights “move” with the new placement of the resource.Further, many resources, e.g., utility programs, can be wild carded intopart of an execution path. In effect, these programs are executed, notout of the original program or process but out of the resource accesstable 166. This provides a simple way to limit access rights—merely bystatements in the resource access table. Moreover, since the substituteddirectory path identified the word processor WP in its executionpath—and not some other resource such as an EXCEL program—access rightsto EXCEL (or any other program that may be part of the system) areexcluded from the WP program execution path.

[0095] Suppose, alternatively, the user is running EXCEL and wishes touse a spell check resource. Unless that spell check resource, whichresides in the WP program, is included in the allowed access rights ofthe RAT entries for the EXCEL program any user attempt to access it fromEXCEL will be denied. It will thus be appreciated that the process-basedsecurity described hereinabove provides the advantages of (1) preventingusers from loading their own applications on a dedicated systemconfigured according to the present disclosure; and (2) preventing usersfrom attempting to access files via uncontrolled ways such as trying toload in a hex editor, e.g., to obtain access to accounting or othersensitive files.

[0096] Example No. 3: Consider a web server (WS) which can execute anycommon gateway interface (CGI) serving a plurality of companies, e.g.,A, B, C, D, E and F. Prefixing is used to distinguish whose CGI isallowed execution (e.g., ABC/CGI for access to ABC/DATA directory butwhich may exclude DEF/CGI) by substitution according to a $E(#) metasymbol that identifies the path that is executable out of the originalstructure in the RAT. In the RAT, as illustrated in Table 4 hereinbelow,it is seen that there are two kinds of entries instead of one: onestatement for the web server, another for the CGI for which accessrights are defined. Table 4 illustrates a fragment of the RAT forExample 3. TABLE 4 Web Server CGI Rights /HTTP /PROGRAMS/$D/$P Execution/PROGRAMS/$D/$P $E(2)/DATA/$P Read, Write

[0097] Here, the path /PROGRAMS/ABC is granted access, according to thestatement $E(2)/DATA/$P.

[0098] The resource access table 166 entries, thus modified by metasymbols, as described hereinabove, define both the access to resourcesand the execution path through the directory. The resource access table166, uniquely determined for the dedicated, single purpose system, iscalled by the request for access made by the application or process.Thus, the entries in the resource access table are, at the same time,both statements of the access rights and statements of the executionpath. In some operations, for example, a meta symbol (identified by a $followed by a character) inserted into a statement in the resourceaccess table may provide for, referring to Table 3:

[0099] (1) association of user identity information with the applicationor process (user ID and a password, e.g.);

[0100] (2) substitution of one user or a group of users for anotheruser;

[0101] (3) substitution of a part of one execution path for another one;

[0102] (4) specifying at what point in the directory path the accessbegins, or how far into the directory the access rights extend; and

[0103] (5) specifying an access path limited to a particular file nameor keyed to the access of a particular file. The meta symbols enablemodifications to the entries in the resource access table 166 withinstructions that define, on the fly, the particular access rightsavailable to a particular process. Thus, instead of just performing astring comparison of the access rights string (with a predetermined setof access rights) the string is read and interpreted, based on itscontent, as it proceeds on the execution path.

[0104] In summary, the process-based security as disclosed hereinaboveis most efficiently applied to specific functions. The operating system162 of the dedicated, single-purpose system 160 is bundled only with thespecific applications 168 needed including the resource access tables166 and the necessary code to implement the use of the meta symbols andthe process-based security access. Only internal resources are affected.Requests for access to resources 172 are processed from within theparticular process or application 168 before invoking the operatingsystem 162 but before the request handler is invoked.

[0105] With reference to FIG. 12, a multi-user process based securitysystem is shown. In the case where the computing environment is acomputer, the multiplicity of users may be accessing the systemsequentially. In the case where the computer environment is shared, suchas a server with a multiplicity of clients, the users may be accessingthe system simultaneously.

[0106] A first user 300 is authenticated by an authentication agent inthe operating system 60 or process-based security module 76 of acomputer. Once the first user 300 has established an authenticatedidentity, the process based security system loads the first userresource access table 312 in database 310. The first user resourceaccess table 312 includes permissions, establishing the resourcesavailable to each process that is available to the first user. A firstprocess permission table 314 includes a list of files, directories andother processes that may be accessed by the first user 300 through thefirst process 302. A second process permission table 316 includes a listof files, directories and other processes that may be accessed by thefirst user 300 through the second process 306. The first process 302sends calls to the OS 60, requesting access to a resource 324. Aprocess-based security module 76 consults database 310 for the firstuser resource access table 312, including the first process resourceaccess table 314. If the requested resource 324 is identified in thefirst process resource access table 314 of the first user resourceaccess table 312, first process 302 is given access to the requestedresource 324.

[0107] When the first user 300 accesses a second process 306, the secondprocess 306 is given access to resources 326 in accordance with a secondprocess resource access table 316 in the first user resource accesstable 312. The resources 324 available to the first user 300 in thefirst process 302 will only be available to the first user 300 in thesecond process 306 where the resource 324 is identified as available tothe first and second processes in their respective process resourceaccess table in the first user resource access table 312.

[0108] A second user 304 is authenticated by the operating system 60.The process-based security module 76 reads the second user resourceaccess table 318 in database 310. When the second user 304 accesses thefirst process 302, the process-based security module 76 checks the firstprocess 302 access permissions with reference to the second processresource access table 320 of the second user resource access table 318.If the second user 304 does not have permission to access the secondprocess 306, there is no second process resource access table in thesecond user resource access table 318, or the second process resourceaccess table for that user is given a null value. A third process 308accessed by the second user 304 is governed by the third processresource access table 322 of the second user resource access table 318.

[0109] The resources available to the first process 302 depend on theidentity of the user that has been identified to the system. The use ofa user name meta-symbol ($U) in the resource access tables allows thesystem to identify resources based on the name of the user associatedwith the process. For example, the resource access table may providepermission for each user to a directory that has been named using theuser name. The multi-user process based security system is particularlyuseful where the system is a web-server or any system having multipleusers and a need to control access.

[0110] Because the operating system checks the authorization of everyresource call, the security of data, such as password files, does notneed to depend on encryption or other forms of masking. Typical priorart systems do not save passwords in cleartext, but instead save hashesof the passwords. When the password is set using a set passwordfunction, the password is hashed and stored in association with ausername. A login process may request a username and password. Thepassword is hashed and the username is used to retrieve the hash of thepassword associated with the username. If the two hashes match, the useris authenticated.

[0111] In accordance with the preferred embodiment, a given resource canonly be accessed by an authorized user using an authorized process. Thisallows a password file to be stored as cleartext, which allows greaterflexibility in the use of the password in key exchange protocols.

[0112] With reference to FIG. 13, a flowchart of an authenticationprocess is shown. The authentication process involves interactionsbetween a user, an authenticating process and an authentication module.The user may be an individual interacting with a single machine, aprocess accessing an authenticating process, a client in communicationwith a server, or any other interactive source of data. Theauthenticating process may be any process that makes an authenticationcall. A typical authenticating process is a login process. Any processthat requires or needs authentication of a user may be an authenticatingprocess. Some of the functions ascribed to the client or user may beperformed by the authenticating process.

[0113] The authentication module works in conjunction with the processbased security system to authenticate users to any process that calls onit. In the simplest embodiment, the authentication module receivesusernames and passwords and compares the received password with a storedpassword associated with the username. In accordance with the preferredembodiment, the authentication module uses a handshaking operation toauthenticate the user.

[0114] The user or client initiates the authentication process in step330. The authentication process may be initiated by executing a loginprogram, by executing a task that calls on a login program, or byselecting some function in a program that requires authentication beforeit will proceed. When the authentication process has been initiated, theauthenticating process sends a request for a random number (RN) from theauthentication module at step 332.

[0115] When the authenticating process sends a request for a randomnumber to the authentication module, the operating system usingprocess-based security will check to see if the authenticating processis authorized to access the authentication module. Only the processeslisted in the resource access table will be able to access theauthentication module.

[0116] The authentication module generates a random number (RN) in step334. In accordance with the preferred embodiment, the random number (RN)is a sixteen byte cryptographically strong random number. In accordancewith the preferred embodiment, the system uses random numbers that arecryptographically strong random numbers, created using processed noise.Other forms of random numbers may be used, as appropriate, includingpseudo-random numbers. Pseudo-random numbers may be necessary inprotocols where the random numbers need to be reproducible. Preferably,the random numbers are sixteen byte random numbers, although any lengthrandom number may be used as appropriate. The authentication modulemodifies the authenticating process' task structure to reflect thepending authentication request and to restrict access to data storagewhere the random number (RN) will be stored in step 336. The randomnumber is stored (RNs) at a designated storage location with restrictedaccess in step 338. The random number (RNa) is also sent to theauthenticating process in step 340. RNs=RNa

[0117] The user enters a username (USERID) and a password (PWa) in step342. In a client/server environment, where a process run on the clientmachine is calling an authenticating process on the server, the username(USERID) and password (PWa) may be kept at the client. In this case, theauthenticating process may forward the random number (RNa) to theclient. The client uses the password (PWa) and the random number (RNa)to generate a hash H(PWa,RNa) at step 344. In accordance with thepreferred embodiment the password (PWa) and the random number (RNa) areconcatenated, with the concatenation serving as the data hashed. A keyedhash function, such as a keyed MD5 hash, may use the password (PWa) asthe data hashed and the random number (RNa) as the key (K).

[0118] In a local environment where a user is communicating directlywith the authenticating process, the user submits the username (USERID)and password (PWa) to the authenticating process. The authenticatingprocess generates the hash H(PWa,RNa).

[0119] In either case, the username (USERID) and the hash H(PWa,RNa) issent to the authentication module in step 346. The authentication modulechecks the task structure of the authenticating process to determine ifthere is an outstanding request for authentication in step 348. If thereis no outstanding request for authentication, the authentication moduledoes not proceed with the authentication process. This deters amalicious user from using a brute force attack against an unchangedstored random number (RNs) by submitting false hashes H(??, RNs) untilauthentication is achieved. By performing this check of the taskstructure, the authentication process changes the random number (RNs)for each attempted authentication, reducing the effectiveness of a bruteforce attack.

[0120] If the task structure of the authenticating process shows apending request for authentication, the authentication module retrievesthe stored random number (RNs) in step 350. The authentication moduleretrieves a stored password (PWs) associated with the username (USERID)at step 352. The authentication module uses the stored password (PWs)and the stored random number (RNs) to calculate a hash H(PWs,RNs) atstep 354. The received hash H(PWa,RNa) is compared to the calculatedhash H(PWs,RNs) at step 356. If the hashes are equal,H(PWa,RNa)=H(PWs,RNs), then the user is authenticated. If the hashes arenot equal, the authentication process fails.

[0121] In either instance, the authentication module modifies the taskstructure of the authenticating process to reflect the completion of thepending authentication process at step 358. This prevents furtherattempts at authentication without generating a new random number (RN).The authentication module may set the user as the username (USERID) inthe task structure of the authenticating process in step 360. Theauthentication is communicated to the authenticating process, which mayset the user as the username (USERID) for the application settings instep 362.

[0122] With reference to FIG. 14, a flowchart for a set password routineis shown. A set password process communicates with an authenticationmodule. The set password process receives an entered username (USERID)in step 635. The users present password (PW) is entered in step 368.Both the username (USERID) and the password (PW) are sent to theauthentication module, where an authentication process is performed instep 366. If the password (PW) is associated with the username (USERID),the authentication is conformed in step 369 and the set password programrequests a new password (PWN) in step 370. The new password (PWN) issent to the authentication module. The authentication module sets thepassword (PW) equal to the new password (PWN) and saves the associatedusername (USERID) and password (PW) in step 372. If the user cannot beauthenticated, the process stops.

[0123] With reference to FIG. 15, a flowchart for a key exchange processis shown. The key exchange protocol is shown as conducted between aclient and server, where the server is operating with a process-basedsecurity system. Those having skill in the art will recognize that thekey exchange can be performed between any process and a process-basedsecurity operating system. In accordance with the preferred embodiment,the functions ascribed to the server are performed primarily by anauthentication module operating in conjunction with the operatingsystem.

[0124] The client, or more specifically a process operating in a clientrelationship with a server, requests a key exchange from the server instep 374. The client sends the username (USERID) to the server in step375, unless the user has already been authenticated to the system, inwhich case the server uses the authenticated username. A user enters apassword (PW) at the client at step 377. The password (PW) is typicallynot transmitted to the server.

[0125] The authentication module in step 376 modifies the client taskstructure to reflect the key exchange process initiation. The servergenerates a first random number (RN1) in step 378 and sends the firstrandom number (RN1) to the client. In accordance with the preferredembodiment, the system uses random numbers that are cryptographicallystrong random numbers, created using processed noise. Other forms ofrandom numbers may be used, as appropriate, including pseudo-randomnumbers. Pseudo-random numbers may be necessary in protocols where therandom numbers need to be reproducible. Preferably, the random numbersare sixteen byte random numbers, although any length random number maybe used as appropriate. Depending on the hash function used, the lengthof the random number and the strength of the randomization function mayaffect the strength of the key generated, so the random numbergeneration process used should be chosen accordingly.

[0126] The server retrieves the password (PW) associated with theusername (USERID) from data storage in step 382. Both the client in step382 and the server in step 384 independently calculate a hash H(PW,RN1)based on the password (PW) and the first random number (RN1). Inaccordance with the preferred embodiment, a keyed MD5 signature functionis used as the key generating hash function. Other signature or hashfunctions with sufficient pseudo-random distributions may be used. Afirst key (K1) is set as equal to the hash H(PW,RN1) in step 386 at theclient and step 388 at the server. In one embodiment, the first key (K1)may be used as a symmetric key for all communications between the clientand server for the session. In the preferred embodiment, the serversends a second random number (RN2) to the client in step 392, and asecond hash is performed by both the client in step 394 and server atstep 396 H(PW,RN2) to generate a second key (K2) at step 400 for theclient and 398 for the server. The first key (K1) may be used tosymmetrically encrypt communications from the server to the client,while the second key (K2) may be used to symmetrically encryptcommunications from the client to the server. Once the keys aregenerated, the authentication module modify the task structure for theclient in step 402, ending the key generation process.

[0127] The process-based security system can be used to facilitatesecure financial transactions over a network. A typical Internetcommerce system allows users to make purchases using a credit card. Inorder to save the user time and encourage further purchases, theInternet commerce system may save the credit card number, as well asother data used to validate the credit card number such as theexpiration date or CCV number. In the event that the Internet commercesystem server is compromised, either by hackers or insiders, the creditcard numbers may be stolen and abused. Implementing a process-basedsecurity system on the Internet commerce system server could secure thecredit card number database, but in some cases the implementation may betoo extensive a change.

[0128] With reference to FIG. 16, a flowchart for a secured financialtransaction in accordance with one embodiment is shown. The transactionis performed by a buyer at a point-of-sale server (POS). Thepoint-of-sale may be a POS terminal at a retail store or a personalcomputer communicating with an Internet commerce server or any otherserver operative in creating a financial transaction between a buyer anda financial institution. The point-of-sale server is communicablyconnected to a process-based security server and a financial server.

[0129] When the buyer initiates the purchase at the point-of-sale serverat step 404, the buyer is typically authenticated to the point-of-saleserver using a standard authentication technique. With knowledge of thebuyer's identity, the point-of-sale server retrieves one or more storedportions of credit card numbers in step 406, allowing the buyer tochoose one of those credit card to complete the transaction. Because thestorage of credit card numbers at the point-of-sale server is insecure,in accordance with one embodiment, the point-of-sale server displaysonly the last four numbers of the credit card numbers, uniquelyidentifying the buyer's credit cards without revealing the actual creditcard number.

[0130] When the buyer has selected a credit-card to use for the purchasein step 408, the point-of-sale server correlates a credit cardidentifier with the portion of the credit card number that has beenselected. The credit card identifier is a number previously defined bythe process-based security server to serve as a representation of thecredit card in communication between the point-of-sale server and theprocess-based security server. The point-of-sale server sends the creditcard identifier to the process-based security server, along with anynecessary transaction data such as the amount of purchase in step 410.

[0131] The process-based security server receives the credit cardidentifier and retrieves the associated credit card number, expirationdata and CCV number from secured storage in step 412. Because theprocess-based security server can control access to the sensitive data,the credit card numbers stored at the process-based security servercannot be compromised by hackers or malicious insiders. The credit cardnumber, along with the expiration date and the CCV number, are sent to afinancial server associated with the chosen credit card in step 414. Thefinancial server processes the transaction and sends a message eitherapproving or denying the transaction to the point-of-sale server in step416. In some embodiments, the message may be sent to the process-basedsecurity server to be forwarded to the point-of-sale server. If thetransaction has been approved, the point-of-sale server completes thetransaction with the buyer in step 418. If the transaction has beendenied, the point-of-sale server informs the buyer of the denial. Ineither case, the process-based security server may generate a new creditcard identifier in step 420. The new credit card identifier is stored inthe process-based server in association with the credit card number dataand sent to the point-of-sale server to replace the old credit cardidentifier in step 422. This continual refreshing of the credit cardidentifier limits any possible damage caused by intercepting acommunication containing the credit card identifier, as the identifierceases to be valid after one attempted use.

[0132] Another use of the process-based security system is for securefile transfer. With reference to FIG. 17, a flowchart for a secure filetransfer process is shown. The process allows Client A, connected to aprocess based security server, to securely transfer a file to Client B.Client A initiates the session with the process-based security server instep 424. The process based security server authenticates Client A,using the authentication protocol outlined previously in step 426.Client A then transmits a file in step 428 to the process-based securityserver for storage in a location that is accessible to Client A andClient B in step 430. When Client B initiates a session in step 432, theprocess-based security server authenticates the identity of Client B instep 434. Once authenticated, Client B is then permitted to access thefile stored in the location accessible to Client A and Client B in step436. Transmission of the file between the clients and the process-basedsecurity server is typically encrypted, using SSL or some otherencryption protocol to secure the data during the network transmissions.

[0133] With reference to FIG. 18, a flowchart of a boot sequence inaccordance with one embodiment is shown. When the boot sequence isinitiated in function block 438, the process-based security serverchecks the hard drive of the process-based security server to check fora boot sector in function block 440. Normally, the boot sector will bepresent on the hard drive, but in the case where a new hard drive hasbeen installed or the boot sector of the hard drive has been damaged,there will not be a working boot sector. In the case where the hard diskis damaged but the hard disk still has a working boot sector, a functionmay be present to allow a user to force the device to boot off of theflash memory. If there is a boot sector detected in decision block 442,the process follows the YES path to boot the process-based securityserver from the hard drive boot sector in function block. If no bootsector is detected, the process follows the NO path to function block446 and the process-based security server boots from a flash memory. Theflash memory boot causes the hard drive to be formatted in functionblock 448 and populates the hard drive with the process-based securitysoftware in function block 450.

[0134] A process-based security system may be used on a server in anetwork computing environment, on any computer or computing device,either in isolation or working as a client connected to a server. Otherdigital devices suitable for implementing operating system level accessprotection, such as laptops, hand-held computing devices, personaldigital assistants (PDA), or cellular telephones, may implementprocess-based security.

[0135] Referring to FIG. 19, a flowchart of a table building process inaccordance with one embodiment is shown. In creating a resource accesstable for use in a system, or for a user of a system, each processavailable to the system or user may be analyzed. A process may be aprogram, driver, applet, script, executable image or basically any formof instruction that could access a resource on a system. Theimplementation of the process will be referred to as code. In functionblock 500, the table-building process analyzes the code. The processcontinues to function block 502 where the process identifies resourcecalls. The code may be analyzed by visual inspection of a writtenembodiment of the code, by a person capable of recognizing resourcecalls. The code may be analyzed by running the program in trace mode,such that each resource call of the code can be identified. The code maybe analyzed by software designed to identify resource calls andperformed automatically or semi-automatically.

[0136] When the resource calls have been identified in function block502, the identified resource calls are sorted and may be assigned areference label in function block 504. The resources called by theresource calls are identified at function block 506.

[0137] At function block 508, permissions are assigned to each possibleresource called by the code. In accordance with the preferredembodiment, the process resource access table is written in an openform, such that only resources listed in the process resource accesstable may be accessed. The process resource access table may also bewritten with a different default, for example, such that any resourcemay be accessed unless listed in the process resource access table.Using the preferred, open form, Table 1 shows two resources available toE:\LOGIN\LOGIN.EXE, the file E:\SYSTEM\PASSWORDS and the executableE:\PROGRAMS/MENU/MENU.EXE.

[0138] When the resources are assigned permissions, the table-buildingprocess writes the process resource access table in the formProcess/resource/permissions in function block 510. If there is noaccess to a resource, in an open form, no entry is added to the resourceaccess table. Decision block 520 determines if there are furtherresources requiring permission assignment.

[0139] If further resources remain, the process follows the NO path tofunction block 508, where the next permission is assigned. If no furtherresources remain, the process follows the YES path to function block 522where the process resource table is compiled with other process resourcetables into a system or user resource access table. When the resourceaccess table has been compiled, it is saved in a predesignated memoryspace at function block 524. The resource access table may be saved inthe predesignated memory space to protect the resource access table as aresource and allow the resource access process to access the resourceaccess table for use.

[0140] With reference to FIG. 20, a process for table-building inaccordance with another embodiment. In creating a resource access tablefor use in a system, or for a user of a system, each process availableto the system or user may be analyzed. A process may be a program,driver, applet, script, executable image or basically any form ofinstruction that could access a resource on a system. The implementationof the process will be referred to as code. In function block 526, thetable-building process analyzes the code. The process continues tofunction block 528 where the process identifies resource calls. The codemay be analyzed by visual inspection of a written embodiment of thecode, by a person capable of recognizing resource calls. The code may beanalyzed by running the program in trace mode, such that each resourcecall of the code can be identified. The code may be analyzed by softwaredesigned to identify resource calls and performed automatically orsemi-automatically.

[0141] When the resource calls have been identified in function block528, the identified resource calls are sorted and may be assigned areference label in function block 530.

[0142] At function block 532, permissions are assigned to each possibleresource called by each resource call. In accordance with the preferredembodiment, the process resource access tables and the resource accesstable are written in an open form, such that only resources listed inthe process resource access table may be accessed. The process resourceaccess table may also be written with a different default, for example,such that any resource may be accessed unless listed in the processresource access table. Using the preferred, open form, Table 1 shows tworesources available to E:\LOGIN\LOGIN.EXE, the file E:\SYSTEM\PASSWORDSand the executable E:\PROGRAMS/MENU/MENU.EXE. All other resources areunavailable to the LOGIN.EXE process.

[0143] When the resources are assigned permissions, the table-buildingprocess writes the process resource access table in the formProcess/resource call/resource/permissions in function block 534. Ifthere is no access to a resource, in an open form, no entry is added tothe resource access table. Decision block 536 determines if there arefurther resources requiring permission assignment.

[0144] If further resources remain, the process follows the NO path tofunction block 532, where the next permission is assigned. If no furtherresources remain, the process follows the YES path to function block 538where the process resource table is compiled with other process resourcetables into a system or user resource access table. When the resourceaccess table has been compiled, it is saved in a predesignated memoryspace at function block 540. The resource access table may be saved inthe predesignated memory space to protect the resource access table as aresource and allow the resource access process to access the resourceaccess table for use.

[0145] With reference to FIG. 21, a process-based security system usingintrusion detection for table building is shown. In this embodiment,when a new application 302 is executed, the process-based security 76uses standard UNIX permissions 542 to determine resource access 324 forthe application 302. As security calls are made by the application 302,the process-based security sends data regarding the security resourcecalls to intrusion detection software 544. The intrusion detectionsoftware 544 determines the nature of the security resource call anddetermines patterns in the security calls that would exemplify “normal”behavior for the application 302. The intrusion detection software 544uses the pattern recognitions and other analysis techniques to determineacceptable resource access for the application 302 and writes a resourceaccess table 312. When the application 302 is run subsequently, theprocess-based security system 76 uses the resource access table 312 todetermine permissions.

[0146] With reference to FIG. 22, a flowchart of a table-buildingprocess using intrusion detection analysis is shown. When an applicationis executed in function block 546, the process continues to decisionstep 548, where the process determines if a resource access table hasbeen defined for the application. If the application has an associatedresource access table, the process continues along the YES path tofunction block 550. The process uses the resource access table.

[0147] If a resource access table has not been associated with theapplication, the process follows the NO path to function block 552, andthe UNIX permissions are used. The process then cycles at decision step554, waiting for a security resource access. When a security resourceaccess occurs, the process continues to function block 556 where accessis determined by the UNIX permissions. The process then reports thesecurity resource access to the intrusion detection software at functionblock 558. The data is analyzed in step 560 and a resource access tableis written at function block 562. If sufficient data has been collectedat decision block 564, the process defines the resource access table forthe application at function block 566. If sufficient data has not beencollected, the process returns to decision block 554 to await asubsequent security resource call.

[0148] With reference to FIG. 23, a functional block diagram of hardwareimplementations 600 of a process-based security system is shown. Asecured system 602 is typically a stand-alone unit such as a personalcomputer, communication device, personal digital assistant, server,internet appliance or any other type of digital device. The securedsystem 602 may include a microprocessor 604 connected to standard memorycomponents such as RAM 610 and ROM 608. The microprocessor 604 may beconnected to an input-output I/O controller 606, which may provide inputand output control for external memory devices such as a optical diskdrive 614, magnetic disk drive 616 or flash memory interface 618. Anoptical disk 615, such as a compact disk or DVD may be inserted into theoptical disk drive 614, which can read data from the optical disk 615. Amagnetic disk 617, such as a floppy disk, may be inserted into themagnetic disk drive 616, which can read data from the magnetic disk 617.

[0149] In the preferred embodiment, the software designed to implementthe process-based security system is stored on a hard drive 616 andloaded into RAM 610 as needed by the microprocessor 604. Anotherembodiment would write the software in an integrated circuit 612, whichcould be accessed by the microprocessor 604 or stored in RAM 610 asnecessary. The integrated circuit 612 could be a read-only memory, aprogrammable read-only memory, an erasable programmable read-onlymemory, an electrically erasable read-only memory, or any other type ofnon-volatile memory. The integrated circuit 612 is typically asemiconductor chip. While the integrated circuit 612 is shown as aseparate chip from the microprocessor 604, it will be recognized bythose having skill in the art that the non-volatile memory of integratedcircuit 612 could be on-board the microprocessor chip 604 or any otherchip used by the system. The integration of the process-based securitysoftware with the CPU may be enhanced by the integration of an extendedCPU instruction set with instructions specific to table processingfunctions. A CPU with an extended instruction set could be made tointeract with other implementations of the process-based securitymethods.

[0150] The software for implementing the process-based security systemcould be written to an optical disk 615, a magnetic disk 617 or a flashmemory 619. The microprocessor can read the software from the memorymedium using the optical disk drive 614, the magnetic disk drive 616 orthe flash memory interface and store it in RAM 610.

[0151] Although the illustrative embodiment has been described indetail, it should be understood that various changes, substitutions andalterations can be made therein without departing from the spirit andscope of the invention as defined by the appended claims.

What is claimed is:
 1. A memory structure storing instructions for amethod of providing access for a user to resources through a process,said method comprising the steps of: receiving user identificationinformation; identifying user resource access information associatedwith the user identification information, wherein the user resourceaccess information includes process resource access informationassociated with a process; determining when an executing processattempts to accesses a specified resource; checking the process resourceaccess information associated with the process when the process attemptsto access the specified resource to determine if access to the specifiedresource by the process is permitted; allowing the process to access thespecified resource if access permission is indicated; and denying theprocess access to the specified resource if access permission is notindicated.
 2. The memory structure of claim 1, wherein said memorystructure is an integrated circuit.
 3. The memory structure of claim 2,wherein said memory structure is a read-only memory integrated circuit.4. The memory structure of claim 3, wherein said read-only memoryintegrated circuit is a programmable read-only memory integratedcircuit.
 5. The memory structure of claim 1, wherein said memorystructure is a flash memory structure.
 6. The memory structure of claim1, wherein said memory structure is an optical storage disk.
 7. Thememory structure of claim 1, wherein said memory structure is a magneticstorage disk.
 8. The memory structure of claim 1, further comprising anextended instruction set.
 9. An integrated circuit storing instructionsfor a method of providing access for a user to resources through aprocess, said method comprising the steps of: identifying processresource access information associated with a process; determining whenthe process attempts to accesses a specified resource; checking theprocess resource access information associated with the process when theprocess attempts to access the specified resource to determine if accessto the specified resource by the process is permitted; allowing theprocess to access the specified resource if access permission isindicated; and denying the process access to the specified resource ifaccess permission is not indicated.
 10. The integrated circuit of claim9, wherein said integrated circuit is a read-only memory.
 11. Theintegrated circuit of claim 10, wherein said read-only memory is aprogrammable read-only memory.
 12. The integrated circuit of claim 11,wherein said programmable read-only memory is an erasable programmableread-only memory.
 13. The integrated circuit of claim 12, wherein saiderasable programmable read-only memory is an electrically erasableprogrammable read-only memory.
 14. A storage medium storing instructionsfor a method of providing access for a user to resources through aprocess, said method comprising the steps of: determining when theprocess attempts to accesses a specified resource; checking the processresource access information associated with the process when the processattempts to access the specified resource to determine if access to thespecified resource by the process is permitted.
 15. The storage mediumof claim 14, wherein said storage medium is an integrated circuit. 16.The storage medium of claim 14, wherein said storage medium is arotating optical storage medium.
 17. The storage medium of claim 14,wherein said storage medium is a rotating magnetic storage medium. 18.The storage medium of claim 17, wherein said rotating magnetic storagemedium is a floppy disk.
 19. The storage medium of claim 16, whereinsaid rotating magnetic storage medium is a compact disk.
 20. The storagemedium of claim 14, further comprising an extended instruction set.